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FOREWORD 


This  report  on  S/Si,  represents  several  years  ot  research  at 
CSRG  on  compiler  development  techniques.  S/SL  has  been  tried 
under  considerable  stress,  in  the  development  of  the  Toronto 
Euclid  compiler,  and  has  been  found  to  be  a  very  effective 
software  tool. 

An  accompanying  technical  report  by  Rosselet,  CSRG-119, 
presents  a  Pascal  subset  (PT)  compiler  developed  using  S/SL. 
Persons  interested  in  using  S/SL  for  production  work,  are  en¬ 
couraged  to  study  Rosselet's  report  and  nis  compiler.  His  com¬ 
piler  is  written  in  a  highly  readable  style  in  the  FT  subset  of 
standard  Pascal,  using  S/SL  as  tne  tecnnique  to  drive  each  of 
three  passes. 

This  report  consists  of  two  separate  papers.  The  first  is  an 
introduction  to  the  S/SL  languaqe  and  technique.  The  second  is  a 
detailed  specification  of  the  S/SL  language. 
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ABSTRACT 


S/SL  ( Syntax /Semant i c  Language)  is  a  language  that  was 
developed  tor  implementing  compilers.  A  subset  called  SL  (Syntax 
Language)  nas  the  same  recognition  power  as  LR(k)  parsers.  Com¬ 
plete  S/SL  includes  invocation  of  semantic  operations  implemented 
in  another  language  such  as  Pascal. 

S/SL  implies  a  topdown  programming  methodology.  First,  a 
data-free  algorithm  is  developed  in  S/SL.  The  algorithm  invokes 
operations  on  "semantic  mechanisms".  A  semantic  mechanism  is  an 
abstract  object,  specified,  from  the  point  of  view  of  the  S/SL, 
only  by  the  effect  of  operations  upon  the  object.  Later,  the 
mechanisms  are  implemented  apart  from  the  S/SL  program.  The 
separation  of  the  algorithm  from  the  data,  and  the  division  of 
data  into  mechanisms  simplifies  the  effort  needed  to  understand 
and  maintain  the  resulting  software. 

S/SL  has  been  used  to  construct  compilers  for  Speckle  (a  PL/1 
subset),  PT  (a  Pascal  subset)  and  Toronto  Fuclid,  it  nas  been 
used  to  implement  scanners,  parsers,  semantic  analyzers  and  code 
generators . 

S/SL  programs  are  implemented  by  translating  them  to  tables  of 
integers,  A  "table  walker"  program  executes  the  S/SL  program  by 
Interpreting  this  table.  The  translation  of  S/SL  programs  to 
tables  is  performed  by  a  program  called  the  S/SL  processor.  This 
processor  serves  a  function  analogous  to  an  LRCk)  parser  genera¬ 
tor. 

The  implementation  of  S/SL  is  quite  simple  and  highly  port¬ 
able,  It  is  availaole  in  a  very  small  subset  of  Pascal  that  can 
easily  be  transl iter ated  into  other  hign  level  languages. 
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INTRODUCTION 


S/SL  is  a  programming  language  developed  at  the  University  of 
Toronto  as  a  tool  tor  constructing  compilers.  It  is  a  very  mod¬ 
est  language,  incorporating  only  the  following  features:  se¬ 
quences,  repetitions  and  selections  of  actions  (statements); 
input,  matching  and  output  of  tokens;  output  of  error  signals; 
subprograms  (called  rules);  and  invocation  of  semantic  operations 
implemented  in  a  base  language  such  as  Pascal.  S/SL  is  a 
language  without  data  or  assignment;  it  is  a  pure  control 
language  ICordy  1980J .  Data  can  be  manipulated  only  via  semantic 
operations. 

This  paper  is  organized  as  follows.  We  give  a  computational 
model  tor  S/SL  and  a  summary  of  features  of  S/SL,  Then,  example 
S/SL  programs  are  given  to  illustrate  the  use  of  S/SL  in  writing 
scanners,  parsers,  semantic  analyzers  and  code  generators.  we 
discuss  the  methodology  of  software  development  used  with  S/SL. 
Next,  we  give  the  relation  of  S/SL  to  the  theory  of  formal 
languages  and  automata.  This  is  followed  by  a  discussion  of  the 
implementation  of  S/SL.  Finally,  we  give  observations  concerning 
the  use  of  S/SL. 
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X.  A  COMPUTATIONAL  MODEL 


3/SL  assumes  tne  computational  model  illustrated  in  the  fol¬ 
lowing  diagram.  There  is  an  input  stream  that  consists  of  to¬ 
kens.  Each  token  is  a  member  of  a  finite  set,  such  as  the  set  of 
ASCII  characters  or  the  set  of  lexical  constructs  in  Pascal 
(including  identifiers,  integers,  keywords  and  operators).  The 
S/SL  program  reads  (accepts)  tokens  one-by-one  from  the  input 
stream  and  emits  tokens  to  an  output  stream.  it  can  also  emit 
error  signals  to  an  error  stream.  Error  signals  are  analogous  to 
tokens,  but  we  do  not  call  them  tokens  to  avoid  confusion  with 
the  input  and  output  streams.  In  most  applications  of  S/SL,  each 
emitted  error  signal  is  transformed  into  an  error  message. 
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Computational  Model  for  S/SL 


The  S/SL  program  transduces  (translates)  its  input  stream  into 
an  output  stream.  For  example,  a  parser  written  in  S/SL  reads  a 
stream  of  tokens  produced  by  a  scanner  and  generates  an  output 
stream  to  be  consumed  oy  the  semantic  analysis  pass  of  the  com¬ 
piler.  Likewise,  a  scanner  written  in  S/SL  reads  a  stream  of 
characters  (its  input  tokens)  and  emits  a  stream  of  tokens  to  be 
consumed  by  tne  parser. 

An  S/SL  program  is  a  set  of  possibly  recursive  rules  (subpro¬ 
grams).  To  support  this  recursion,  the  implementation  uses  an 
implicit  stack  of  return  addresses,  to  allow  a  called  rule  to 
return  to  the  appropriate  calling  point.  The  return  stack  is  of 
little  interest  except  that  in  terms  of  automata  theory  it 
corresponds  to  tne  stack  of  a  pushdown  automaton. 

Besides  controlling  the  input  and  output  streams,  the  S/SL 
program  can  manipulate  data  using  semantic  operations  that  are 
organized  into  modules  called  s.£maai.Lc  .  The  interface 
to  each  semantic  mechanism  is  defined  in  S/SL,  DUt  the  implemen¬ 
tation  is  hidden.  The  implementation  is  done  separately  in  a 
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oase  language  such  as  Pascal.  The  S/SL  program  invokes  semantic 
operations  to  inspect  or  manipulate  data,  but  has  no  other  access 
to  data.  It  has  no  direct  data  Handling  capabilities  such  as 
assignment  or  comparison. 

The  symbol  table  is  the  most  important  semantic  mechanism  in  a 
typical  compiler.  In  building  a  semantic  analysis  pass,  one 
would  define  this  semantic  mechanism  by  specifying  operations 
such  as  the  following: 

Enter  a  symbol  into  the  symbol  table 
Look,  up  a  symbol  in  the  symbol  table 
Start  a  new  scope  in  the  symbol  table 
finish  a  scope  in  the  symbol  table 

The  S/SL  programmer  need  not  be  directly  concerned  with  the  im¬ 
plementation  of  the  operations.  In  writing  his  S/SL  program  he 
needs  to  know  only  tneir  meaning  (specif ication) .  This  is  analo¬ 
gous  to  specifying  an  abstract  data  type  and  using  it  without 
being  concerned  with  its  implementation. 

In  certain  instances  a  semantic  mechanism  (or  at  least  its 
data)  may  be  preserved  beyond  the  termination  of  a  particular 
S/SL  execution,  Eor  example,  one  pass  of  the  Toronto  Euclid  com¬ 
piler  LHolt  1978,  CSRG  1980]  creates  a  symbol/type  table  that  is 
used  by  successive  passes. 

A  parser  pass  of  a  compiler  may  not  require  semantic  mechan¬ 
isms,  because  S/SL  witnout  semantic  mechanisms  is  powerful  enough 
to  do  syntax  checking. 
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li.  FEATURES  OF  S/SI 


First  we  will  describe  the  features  of  SL,  which  is  S/SL 
without  semantic  mechanisms.  Each  SL  proqram  consists  of  a  list 
of  executable  rules.  Each  rule  consists  of  a  name,  an  optional 
return  type  and  a  sequence  of  actions  (statements).  Each  rule 
has  one  of  these  two  forms: 

name:  actions; 

name  >>  type:  actions; 

A  rule  with  the  first  form  is  called  a  ajmcadute  rule;  a  rule 
with  the  second  form  is  called  a  ctuaics.  rule.  These  two  forms 
are  analoqous  to  procedures  and  functions  in  Pascal.  Execution 
begins  with  the  first  rule  of  the  S/SL  program,  which  must  be  a 
procedure  rule.  A  rule  returns  when  it  reaches  its  end  (;)  or  it 
encounters  a  return  action  (written  >>).  A  choice  rule  returns  a 
value  in  its  specified  type  (a  range),  which  is  tested  in  a 
choice  action  (see  below). 


Summary  of  SL  Actions 

There  are  only  eight  different  actions  (statements)  in  SL. 
These  are  now  described. 

1.  The  iauut  (or  match)  action.  The  appearance  of  an  input  token 
in  a  rule  signifies  that  the  next  input  should  be  read  and  must 
match  the  specified  token.  For  example,  the  followina  specifies 
that  the  next  item  in  the  input  stream  is  to  be  read  and  it  must 
be  an  integer  token: 

integer 

The  appearance  of  a  question  mark  in  a  rule  signifies  that  the 
next  token  (whatever  it  is)  is  to  be  read.  The  ?  matches  any 
token . 

2.  The  emit  action.  The  appearance  of  a  dot  (a  period)  followed 
by  an  output  token  signifies  that  the  token  is  to  be  emitted  to 
the  output  stream,  for  example: 

.add 

causes  an  add  token  to  be  emitted  to  the  stream. 

3.  The  ccxat  action.  The  appearance  of  the  symbol  #  followed  by 
an  error  signal  signifies  that  the  error  signal  is  to  be  emitted 
to  a  special  error  stream,  for  example: 

#missingSemicolon 

The-signal  called  misslngSemicolon  is  output  to  the  error  stream; 
presumably  this  stream  is  used  to  print  error  messages. 
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4.  The  cy.de  action 


Each  cycle  is  of  the  form 


{ 

ac  t ions 

> 

The  enclosed  actions  are  repeated  until  a  return  (>>)  or  one  of 
the  cycle's  exits  (>)  is  encountered. 

5.  The  exit  construct.  The  appearance  of  the  symbol  >  signifies 
exit  from  the  most  tightly  enclosing  cycle. 

6.  The  ctdce  action.  The  chdce  action  is  of  the  form: 

t  selector 
I  labels: 

ac t ions 
I  labels: 
actions 

f  •  • 

I  * : 

actions 

3 

The  selector  is  optional.  if  it  is  omitted,  we  have  an  inaut 
claaicfi,  which  tries  to  match  the  next  input  token  to  one  of  the 
labels.  The  selector  can  also  be  of  the  form  ^identifier  where 
"identifier"  is  the  name  of  a  choice  rule?  this  qives  us  a  xule, 
cUaice.  In  a  rule  choice,  the  specified  rule  is  called  and  then 
the  choice  tries  to  match  the  returned  value  to  one  of  the  la¬ 
bels.  There  is  also  a  s.e.macLic  cJaaica,  in  which  the  selector  is 
the  name  of  a  semantic  operation?  semantic  choices  are  in  S/SL# 
but  not  in  SL.  The  actions  associated  with  the  matched  label  are 
executed?  if  no  label  is  matched,  the  final  alternative,  labelled 
by  the  star  (*),  is  executed. 

The  otherwise  clause: 


I  *: 

actions 

is  optional.  If  omitted,  the  selector  oust  match  one  of  the 
choice's  labels  (otherwise  there  is  an  error).  In  an  input 
choice,  the  matching  of  the  input  token  to  a  label  has  the  side- 
effect  of  reading  another  token?  if  the  token  is  not  matched  and 
the  otherwise  clause  is  selected,  then  reading  is  aa L  done. 

Each  alternative  in  a  choice  can  have  several  labels,  separat¬ 
ed  by  commas?  for  example,  this  alternative  has  as  labels  the 
tokens  plus  and  minus: 

I  '+', 

integer 

Each  label  in  a  given  choice  construct  must  be  of  the  same 
type  as  the  selector,  and  each  label  of  the  choice  must  be  a 
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distinct  value.  For  input  choices,  the  labels  must  be  input 
tokens.  For  rule  choices,  the  labels  must  be  of  the  type  re¬ 
turned  by  the  rule,  for  example 

[  ^Optional  Expression 
I  true: 

actions 
I  false: 
actions 

3 

where  the  range  of  OptionalExpression  is  Boolean. 

When  writing  a  parser  it  is  common  to  use  an  input  choice  that 
accepts  a  particular  limited  set  of  tokens,  with  no  otherwise 
clause.  We  do  this  in  spite  of  the  fact  that  a  syntax  error  may 
cause  the  next  input  token  to  fall  outside  this  set.  When  the 
next  token  is  not  acceptable,  we  rely  on  error  handling  logic  to 
either  abort  the  SL  program  or  to  repair  the  input  stream  to  be 
acceptable  by  the  input  choice.  The  usual  repair  strategy  is  to 
take  the  first  choice  in  case  of  such  an  error,  and  to  modify  the 
input  stream  accordingly,- 

7.  The  call  action.  The  appearance  of  the  symbol  «  followed  by 
the  name  of  a  procedure  rule  signifies  that  the  rule  is  to  be 
called.  For  example,  here  is  a  call  to  the  Expression  rule: 

@Expression 

8.  The  caluin  action.  The  symbol  >>  in  a  rule  signifies  return 
before  reaching  the  end  of  the  rule.  In  choice  rules,  the  >> 
must  be  followed  by  a  value  in  the  rule's  specified  return  type, 
and  implicit  return  via  the  final  semicolon  is  not  allowed.  In 
procedure  rules,  the  return  >>  cannot  be  followed  by  a  value. 
Usually  >>  is  not  used  in  procedures  because  return  is  implicit 
at  the  end  of  the  rule.  Here  is  a  choice  rule,  OptionalExpres¬ 
sion,  that  returns  true  if  the  next  token  is  the  end-of-file? 
otherwise  it  parses  an  expression  and  returns  false. 

OptionalExpression  >>  Boolean: 

C 

!  eof : 

>>  true 
I  *: 

^Expression 
>>  false 

]  ? 

This  completes  a  summary  of  the  actions  in  SL.  The  actions  in 
S/SL  are  the  same  with  the  addition  of  calls  to  semantic  opera¬ 
tions  , 
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Definitions  in  S  L 


we  need  to  make  certain  definitions  that  are  used  bv  SL  rules. 
In  particular  we  need  to  specify  the  set  of  input  tokens,  the  set 
of  output  tokens,  the  set  of  error  signals  and  the  set  of  values 
returned  by  each  choice  rule  land  by  each  semantic  operation). 
Each  of  these  sets  is  defined  by  enumerating  the  names  of  their 
members;  this  is  similar  to  defining  enumerated  types  in  Pascal. 
For  example; 

input : 

integer 
Plus  '  + ' 
minus  # - ' 
assign 
...etc.../ 

output; 

Int 
Add 
Subt 

...etc..., 

error ; 

missing  Semicolon 

...etc...; 

type  Boolean; 
false 
t  r  ue  ; 

Here  we  have  also  shown  the  convention  for  comments  in  S/SL  pro¬ 
grams,  namely,  anything  to  the  right  of  a  %  on  a  line  is  ignored. 

Each  token  and  error  signal  must  be  given  a  name,  such  as 
integer  or  Subt.  The  input  and  output  tokens  can  also  be  given  a 

string  name,  for  example,  the  plus  token  also  has  the  name  '  + 

Both  names  can  be  used  in  the  S/SL  program. 

In  the  case  of  the  name  "plus"  seems  to  be  useless,  as  it 

is  defined  but  need  not  be  used  in  the  S/SL.  The  reason  that 
identifiers  such  as  plus  are  reauired  is  that  they  are  used  in 
the  implementation  of  S/SL.  For  example,  if  the  implementation 
is  done  using  Pascal,  the  "plus"  will  be  declared  as  a  Pascal 
named  constant  wnose  value  is  the  token's  number. 

The  S/SL  programmer  can  specify  the  internal  value  of  each 
token,  in  order  to  be  compatible  witn  an  external  interface,  for 
example , 


%  Input  tokens 


%  Output  tokens 


%  Frror  signals 

%  User  defined  set  of  values 


plus  =  21 

This  assigns  the  internal  token  number  21  to  "plus". 

Sometimes  it  is  convenient  to  emit  the  same  tokens  that  are 
read.  To  allow  this,  a  special  class  called  "input  output"  is 
allowed,  for  example: 
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input  output:  %  Used  tor  both  input  and  output 

integer 
Plus 
minus 

. , e tc . . . ; 

Any  token  listed  under  ‘'input  output"  is  included  in  both  the 
input  and  output  types. 


Semantic  Mechanisms 

SL  is  sufficient  for  implementing  parsers  tor  lanauaqes  havinq 
LR(k)  grammars,  such  as  Pascal  and  Algol-60.  However,  SL  by 
itself  is  not  sufficient  tor  implementing  more  complex  phases  of 
a  compiler,  such  as  semantic  analysis.  It  does  not  provide  for 
data  structures,  such  as  symbol  tables,  which  are  required  by 
these  phases.  SL  as  augmented  by  semantic  operations  becomes 
S/SL.  The  S/SL  programmer  groups  the  operations  that  access  a 
particular  data  structure;  these  operations  together  with  the 
data  structure  are  called  a  semantic  macfraalsm. 

As  a  simple  example  of  a  semantic  mechanism,  let  us  consider  a 
stack  of  counters.  As  is  shown  in  the  next  section,  this  mechan¬ 
ism  can  be  used  for  checking  the  number  of  actual  parameters  of  a 
Pascal  procedure  call.  The  operations  that  modify  and  update  the 
stack  are  defined  in  S/SL,  but  the  implementation  is  carried  out 
later  in  another  language.  Here  is  the  definition  in  S/SL  of  a 
stack  of  counters: 

mechanism  Count: 

CountPush(number)  %  New  counter  gets  specified  value 

CountPushSymbolDimens i on  %  New  counter  gets  value  from  symbol 

%  table 

CountPop  %  Delete  counter 

Count  Increment  %  Add  1  to  top  counter 

CountDecrement  %  Subtract  1  from  top  counter 

CountChoose  >>  number;  %  Inspect  top  counter 

Following  the  keyword  "mechanism"  is  the  name  of  the  mechanism 
(Count!.  This  name  has  no  significance  except  for  documentat ion. 
After  the  colon  comes  the  list  of  semantic  operations  for  the 
mechanism. 

By  convention,  the  name  of  each  operation  on  a  semantic 
mechanism  begins  with  the  mechanism's  name.  For  example,  Buffer- 
Save  is  an  operation  on  the  Buffer  mechanism,  while  CountPop  is 
an  operation  on  the  Count  mechanism. 

We  have  defined  six  semantic  operations  for  the  count  stack, 
the  first  five  are  uodate  operations;  they  are  defined  without  a 
return  type  (without  >>).  Their  purpose  is  to  modifv  the  seman¬ 
tic  mechanism.  The  last  operation,  CountChoose,  is  a  Gfuaice. 
operation.  A  choice  operation  returns  a  value  that  is  used  in  an 
S/SL  choice  action. 
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By  convention  a  choice  operation  returns  information  about  its 
semantic  mechanism  but  does  not  modify  it.  Also  by  convention, 
operations  on  one  semantic  mechanism  may  inspect  but  not  modify 
other  semantic  mechanisms.  These  conventions  depend  on  proqram- 
mer  discipline  and  are  not  enforced  automatically. 

The  first  operation,  CountPush,  puts  a  new  value  on  the  count 
stack;  for  example,  CountPush ( zero )  pushes  zero  onto  the  stack. 
Since  CountPush  takes  a  parameter,  it  is  called  a  aataafitetized 
operation,  A  parameter  of  a  par ameter ized  operation  must  be  a 
constant  in  a  previously  defined  set  of  values  in  the  S/SL  pro¬ 
gram,  Essentially  a  parameterized  operation  is  a  class  of  non¬ 
parameter  ized  operations,  one  for  each  constant  in  the  type. 

The  last  semantic  operation,  CountChoose,  is  called  to  find 
the  top  value  on  the  count  stack.  The  notation  ">>  number"  means 
it  returns  a  value  from  the  type  named  "number".  A  choice  opera¬ 
tion  can  be  used  only  in  S/SL  choice  actions,  for  example,  see 
line  12  ot  the  following  example  rule. 


An  Example  Usina  the  Count  Stack 

We  now  qive  an  example  S/SL  rule  that  uses  the  count  stack. 
This  example  rule  handles  a  list  of  actual  parameters  for  a  pro¬ 
cedure  call  in  a  language  such  as  Pascal, 

1  ActualParameterList : 

2  CountPushSymbolDimension  %  Number  of  formal  parameters 

3  < 

4  i?HandleActualParameter 

5  Coun tDecrement 

b  [ 

7  I  f ) # ; 

B  > 

9  I  * , ' ; 

10  J 

11  > 

12  C  CountChoose 

13  I  zero; 

14  1  * : 

15  # Wr ongNumberParameters 

16  J 

17  CountPop; 

Suppose  the  Pascal  procedure  call  is 

P ( exp  1 , exp2 ) ; 

The  procedure's  name  P  is  accepted  by  the  S/SL  proqram  and  be¬ 
comes  the  current  symbol  of  interest.  Then  the  left  parenthesis 
is  accepted  and  finally  the  Act ualParameterList  rule  is  called. 
Line  2  finds  the  declared  number  of  parameters  of  P  and  pushes 
this  number  onto  the  count  stack.  Then  the  loop  (lines  3  through 
11)  processes  the  list  of  actuals,  decrementing  the  count  for 
each  actual.  HandleActualParameter  will  accept  "expl "  the  first 


time  through  the  loop  and  "exp2"  the  second  time.  Then  lines  12 
through  16  print  an  error  message  if  the  wrong  number  of  actual 
parameters  was  supplied.  Line  17  pops  the  counter  that  was 
pushed  on  line  2. 

In  Pascal  an  actual  parameter  may  contain  function  calls,  so 
the  ActualParameterLis t  rule  may  be  re-entered  recursively.  Each 
recursion  needs  a  new  counter,  and  the  count  stack  is  used  to 
store  these  counters. 

This  example  has  illustrated  how  to  define  and  use  semantic 
operations.  Each  operation  performs  an  update  or  a  choice  and 
may  be  parameterized.  We  have  given  an  example  of  a  Darameter- 
less  choice  operation  (CountChoose)  but  not  a  parameterized 
choice  operation,  which  is  defined  using  this  form: 

name  (paraineterType )  >>  returnType 

A  parameterized  choice  operation  is  similar  to  a  parameter  less 
choice  operation  except  it  receives  a  constant  as  a  parameter. 

We  have  shown  how  to  define  the  names  of  semantic  operations 
as  well  as  their  parameter  and  return  types,  but  we  have  not 
shown  how  to  give  their  implementations.  Before  going  into  the 
details  of  these,  we  will  give  several  more  example  S/SL  pro¬ 
grams. 


III.  EXAMPLES  OF  5/SL  usf: 


The  following  examples  illustrate  the  use  o£  S/SL  in  imple¬ 
menting  a  compiler.  We  start  with  scanning  and  proceed  eventual¬ 
ly  to  code  generation  tor  a  PDP-1 t . 


Scanning 

The  purpose  of  our  example  scanner  is  to  collect  the  charac¬ 
ters  of  a  source  program  into  syntax  tokens,  Leadina  blanks  are 
skipped  and  the  characters  of  the  syntax  token  are  collected  by  a 
semantic  operation  named  BufferSave,  we  will  assume  that  an 
input  filter  for  our  scanner  has  mapped  the  characters  A  through 
Z  to  a  s.uoat  cfiat.acXat  called  "letter"  and  the  characters  0 
through  9  to  "digit". 

This  example  is  a  complete  S/SL  program  that  can  he  submitted 
to  an  S/SL  processor.  The  first  part  consists  of  definitions. 
The  second  part,  between  the  words  "rules"  and  "end",  gives  the 
S/SL  rules. 

%  A  scanner  tor  identifiers,  integers,  and 

input: 

letter 

digit 

blank 

i 1 legalChar ; 

output : 

ident i tier 
integer ; 

input  output: 

semicolon  '  ?  ' 
plus  * +  * 

minus 

error : 

badChar ; 

mechanism  Buffer: 

BufferSave;  %  Save  last  accepted  character 

rules 

Scanner: 

^Skio Noise 
t 

I  letter: 

BufferSave 
{  [ 

I  letter  , digi t : 

BufferSave 


I  * : 

• ident i f ier 
> 

3  > 

I  digit: 

Buf  f erSave 
{ [ 

I  digit: 

Buf  terSave 

I  *: 

•  inteqer 
> 

J  > 

I  '  #•  * : 

•  semicolon 
I  f  +  # : 

•  plus 
I  •-• : 

.minus 

3? 

SkipNoise : 

<  t 

I  blank: 

I  illegalChar; 

UbadChar 
l  *: 

> 

3  >  ? 

end 

This  scanner  is  a  simplified  version  of  the  one  used  in  the  PT 
Pascal  compiler  [Hosselet  1980J.  This  example  uses  the  notation 
{l  and  ]}.  This  is  not  a  new  construct#  but  simplv  a  choice 
action  nested  directly  inside  a  cycle. 


Parsinq 

It  is  straightforward  to  write  a  parser  for  a  lanauaqe  such  as 
Pascal  in  S/SL.  The  Pascal  report  [Jensen  19743  contains  a 
specification  of  the  grammar  of  Pascal  in  the  form  of  syntax 
charts.  These  charts  are  easily  transliterated  to  S/SL#  to  pro¬ 
duce  a  grammar  for  Pascal  in  S/SL,  We  call  this  an  alaaaLLLiii.LG 
atammaa#  because  it  can  be  directly  executed  to  accept  a  string 
in  the  specified  language.  We  will  give  three  examples  of  pars¬ 
ing:  recoqnizing  a  statement#  handlinq  an  "if"  statement  and  pro¬ 
ducing  postfix  for  expressions. 

Re.caaaiLiaa  s.JLALe.me.aLs. .  A  Pascal  statement  can  be  recognized 
by  the  following  rule. 

Statement : 

[ 

I  identifier: 
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iMssignmentGrCall  Statement 
I  '  if  ' ; 

Olf Statement 
I  'case': 

(aCaseStatemen  t 
l  '  whi  ie  ' : 

@While Statement 
I  '  repeat ' : 

(aRepeatStatement 
I  ' f or  ' : 

@ForStatement 
I  'with': 

aWithStatement 
I  'begin': 

OBeg inStatement 
I  'goto': 

@GotoSt at ement 
I  * : 

%  null  statement 

)  ; 

Each  individual  statement  such  as  'it'  is  handled  bv  its  own 
rule.  Untor tunately  tor  the  parser,  there  is  a  local  ambiquity 
in  Pascal  in  that  a  statement  beginning  with  an  identifier  can  be 
either  an  assignment  or  a  procedure  call,  so  one  rule  must  handle 
both, 

Uandliaa  HJLf."  sXaLe.aenX.5.  As  an  example  of  a  rules  for  indi¬ 
vidual  statements,  we  will  give  a  rule  to  handle  "if". 

ifStatement:  %  Just  accepted  'it'  token 

{^Expression  'then'  ^Statement 
[ 

I  'else ' : 

^Statement 
I  * : 

J  ? 

This  rule  recursively  calls  the  Statement  rule  to  handle  'then' 
and  'else'  clauses.  The  "dangling  else"  problem  is  easily 
solved,  as  the  cnoice  construct  immediately  accepts  the  adjacent 
else  clause  if  present.  We  have  not  shown  output  operations  or 
calls  to  semantic  operations;  these  can  be  inserted  to  make  this 
example  rule  useful  in  a  compiler. 

/ 

E.X£E.e.s£iaas  aad  We  now  show  how  expressions  can  be 

parsed.  To  keep  tne  example  simple,  we  restrict  our  attention  to 
expressions  that  consist  of  identifiers,  the  binary  operators  t , 
-,  *  and  /,  and  nesting  via  parentheses.  We  assume  that  expres¬ 

sions  are  evaluated  left  to  right  except  that  *  and  /  have  higher 
precedence  than  +  and  -  and  parenthesized  subexpressions  are 
evaluated  before  use.  fne  example  S/SL  will  transduce  infix  to 
postfix,  for  example,  the  input  stream 

A  +  B  *  C 


lb 


is  output  as 


A  B  C  multiply  add 

Here  are  rules  that  handle  expressions: 

Expression : 

^Factor 

<  [ 

I  #  +  # : 

^Factor 

I  ; 

^Factor 
I  *: 

> 

3  > ; 

Factor : 

®Pr imary 
<  [ 

I 

0Pr itnar y  .multiply 
l  V': 

'^Primary  .divide 
I  *: 

> 

]>; 

Primary: 

[ 

l  #  ( ' : 

0 Expression  * )  * 

I  identifier: 

.identifier  EmitldentifierText 

3; 

The  Expresson  rule  calls  the  Factor  rule  to  handle  all  hiqh  pre¬ 
cedence  operations  and  subexpressions  before  handlino  addition 
and  subtraction.  vSimilarly,  Factor  calls  Primary  before  handlino 
multiplication  and  division.  Primary  calls  Expression  recursive¬ 
ly  to  handle  nested  expressions.  Since  each  identifier  token  has 
a  value  (such  as  ‘’A”  or  "B"),  we  have  used  the  semantic  operation 
EmitldentifierText  to  place  this  value  in  the  output  stream. 


•  add 

. subtract 


Semantic  Analysis 

We  take  as  a  typical  semantic  analysis  task  the  problem  of 
checking  types  in  expressions.  we  can  ao  this  usinq  a  semantic 
mechanism  called  the  si.acJ£.  it  mimics  the  action  of  a  run¬ 
time  stack  used  in  evaluating  expressions.  Each  entry  in  the 
type  stack  gives  the  type  of  the  corresponding  operand  in  the 
runtime  stack.  The  definition  in  S/Sh  of  this  semantic  mechanism 
would  be  similar  to  the  definition  we  gave  for  the  stack  of 
counters.  we  will  assume  that  the  input  to  our  semantic  analysis 
pass  has  its  expressions  in  syntactically  correct  postfix.  This 
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rule  is  used  to  accept  expressions: 

PostfixExpression: 

^Primaries  ^Operators 
[ 

t  exprKnd: 

> 

I  *: 

1 

>  ? 

we  have  assumed  that  the  token  exprtnd  marks  the  end  of  each 
expression.  To  simplify  our  example,  we  consider  only  these 
operators:  addition,  equality  and  intersection  (and).  As  in  Pas¬ 
cal,  we  assume  that  only  numbers  can  be  added,  only  BooLeans  can 
be  intersected,  numbers  can  be  compared  to  numbers  only  and 
Booleans  to  Booleans  only.  We  assume  that  all  numbers  are  in¬ 
tegers  . 

As  each  primary  is  accepted,  its  type  is  pushed  onto  the  type 
stack.  As  each  operator  is  accepted,  the  types  of  its  operands 
are  checked  and  their  types  on  the  type  stack  are  replaced  by  the 
operator's  result  type. 

Primaries: 

<  [ 

I  constant:  TypePushCons tant 
...other  primaries... 

I  *: 

> 

3  >  ? 

Operators : 
i  C 

I  add : 

PChecklnteger  t^Check Integer  TypePushC int) 

I  and : 

PCheckBoo lean  ^CheckBoolean  I ypePush ( bool ) 

I  equal: 

^CheckEgual I ty  TypePush ( bool ) 

I  *: 

> 

3 > ; 

Check  I nteqer : 

[  TypeChoose 
I  int : 

I  * : 

# integer  Hequi red 
J 

TypePop ; 

CheckBoo lean : 
f  TypeChoose 
I  bool: 
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#booieanRequired 


I  * 


J 

TypePop ; 

CheckEnuality : 

[  TypeChoose 
i  i  nt : 

TypePop  GChecklnteger 
I  bool: 

TypePop  @CheckBoolean 

J ; 

We  could  easily  enhance  these  rules  to  produce  pseudo-machine 
code  (P-code)  while  they  are  checking  types.  We  could  incor¬ 
porate  this  type  checking  into  the  pass  that  does  syntax  checking 
(the  parser). 


Code  Generation 

The  code  generator  pass  of  the  Toronto  Euclid  comojler  accepts 
expressions  in  postfix  and  generates  PDP-11  assembly  language. 
It  does  extensive  local  optimization,  to  take  advantage  of  the 
PDP-11  order  code.  To  illustrate,  we  show  a  simplified  version 
of  the  rule  that  generates  code  to  add  the  riqht  operand  to  the 
left.  We  will  assume  that  previous  analysis  by  S/SL  in  this  pass 
has  discovered  that  the  source  statement  is  of  the  form 

x  :=  x  t  y 

and  now  y  is  the  right  operand  and  x  is  the  left.  A  semantic 
mechanism  called  the  s,*mb.al  SLlacfc  holds  these  operands#  with  the 
right  operand  as  its  top  element  and  the  left  operand  as  its 
second  element.  The  rule  pops  the  top  (right)  element  from  the 
symbol  stack,  leaving  the  left  (new  top)  element  to  represent  the 
result . 

AddRightToLeft : 

[  Symbol IsMani test Val ue  %  Is  right  operand  a  constant? 

I  yes : 

(  SymbolChooseMani f estValue 
I  one : 

SymbolPop  Genera teSing let inc) 
i  zero: 

SymbolPop  %  Generate  nothing 
I  minusOne: 

SymbolPop  Gene rates ingle ( dec ) 

I  *: 

Generat ef)oub le  ( add )  SymbolPop 

J 

I  no : 

(  Symbol IsLef. tSameHight  %  Adding  x  to  x? 

I  yes : 

SymbolPop  GenerateSinqle(asl) 

I  no : 
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J 


GenerateDouble (add)  Symbol  Pop 


1  ? 

This  S/SL  rule  selectively  generates  the  following  PDP-11  code: 

Riabt  UuExaad,  RUEsll  code,  aaaatated. 

1  inc  left 

0  (no  code) 

-1  dec  left 

same  as  lett  operand  asl  left 

otherwise  add  right, left 

The  parameterized  semantic  operation  Generates  ingle  emits  a 
PDP-11  single  operand  instruction  such  as  inc  (Increment),  dec 
(decrement)  or  asl  (arithmetic  shift  left).  Similarly#  Genera- 
teDouble  generates  double  operand  instructions  such  as  add. 


Readability  and  Special  Characters 

The  preceding  set  of  examples  is  intended  to  demonstrate  the 
power,  convenience  and  expressiveness  of  S/SL,  In  practice,  S/SL 
has  been  found  to  be  quite  readable  and  maintainable.  A  question 
that  arises  is  why  special  characters  rather  than  keywords  are 
used  to  denote  control  constructs.  People  who  are  used  to  pro¬ 
gramming  in  Pascal-like  languages  are  surprised  to  find,  for 
example,  that  a  choice  action  is  written  as  l , , ,  I  . , .  I  . . .  1  instead 
of  case , , .of , , , end,  While  no  objective  explanation  is  possible, 
the  following  observations  are  put  forth. 

Before  developing  S/SL,  the  authors  used  syntax  and  semantic 
charts  (Barnard  1975,  Cordy  1976,  Cordy  1979);  these  charts  were 
hand  translated  into  an  assembly-like  notation  that  used  key¬ 
words,  It  was  observed  that  this  latter  notation  was  consider¬ 
ably  bulkier  and  clumsier  than  the  charts.  This  led  to  experi¬ 
mentation  with  various  notations,  especially  those  used  for  regu¬ 
lar  expressions. 

It  was  discovered  tnat  essentially  all  the  readability  of 
charts  could  be  maintained  using  S/SL,  and  besides,  S/SL  can  be 
directly  processed  by  a  computer.  This  degree  of  readability 
depends  on  (1)  consistent  indentation  of  choices  and  cycles  so 
these  constructs  are  visually  obvious  and  (2)  sufficient  exposure 
of  the  reader  to  the  S/SL  notation,  so  that  he  immediately  asso¬ 
ciates  (...)  with  selection  and  (...)  with  repetition. 

In  hindsight,  it  appears  that  special  characters  are  suitable 
for  S/SL  because  it  is  such  a  small  language.  The  fact  is,  S/SL 
contains  only  eight  actions,  plus  calls  to  semantic  operations. 
It  has  no  arithmetic  or  addressing  operators.  Thus  it  is  natural 
to  use  a  concise  notation  (special  characters)  to  represent  the 
tew  existing  features.  Conversely,  It  is  not  necessary  to  intro¬ 
duce  the  relatively  bulky  framework  implied  by  keywords  such  as 
"case”,  "loop",  and  "exit".  Kor  analogous  reasons,  notations 
such  as  BNF'  and  regular  expressions  use  special  characters  such 
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as  "  and  "I"  rather  t nan  bulkier  symbols  such  as  "repeated"  and 
" or",  (See  also  Hoare's  defense  of  his  use  of  special  characters 
in  Communicating  Sequential  Processes  [Hoare  1978].) 

Unfortunately,  some  computer  systems  do  not  support  special 
characters  such  as  {  and  l.  As  a  concession  to  portability,  our 
S/SL  implementation  allows  da  and  ad  as  substitutes  for  <  and  >, 
it  and  ti  tor  l  and  ] ,  and  !  for  I .  We  have  chosen  very  short 
Keywords,  such  as  da  and  it,  to  preserve  most  of  the  concise  rea¬ 
dability  Of  S/SL. 
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JV.  PROGRAMMING  METHODOLOGY 


The  programming  methodology  associated  with  S/SL  is  perhaps  as 
important  as  the  notation  Itself.  Briefly,  this  methodology  con¬ 
sists  of  breaking  the  problem  solution  into  two  distinct  parts: 
the  abstract  algorithm  (implemented  in  S/SL)  and  the  apstract 
data  (written  in  a  base  language  such  as  Pascal).  The  abstract 
data  is  further  divided  into  largely  independent  semantic  mechan¬ 
isms.  Each  semantic  mechanism  is  an  abstract  machine  that  can 
carry  out  a  well-defined  set  of  instructions  (its  semantic  opera¬ 
tions  ) . 

Since  the  abstract  algorithm  is  written  in  a  different 
language  from  that  used  to  implement  the  semantic  mechanisms,  it 
is  inevitable  that  we  maintain  the  distinction  between  the  two. 
By  comparison,  if  we  did  not  use  S/SL  and  we  wrote  both  in  a 
language  such  as  Pascal,  these  divisions  would  be  easily  over¬ 
looked,  especially  during  maintenance. 

The  definition  in  S/SL  of  the  name  of  each  semantic  mechanism 
along  with  its  operations  serves  as  a  concise,  readable  summary 
of  the  underlying  data  of  the  program.  The  programmer  is  expect¬ 
ed  to  include  comments  with  these  definitions  that  qive  the  mean¬ 
ing  (specification)  of  each  operation.  These  comments  could  use 
a  notation  such  as  that  of  abstract  data  types,  and  could  serve 
as  a  formal  spec! f ication  of  the  semantic  mechanism.  However, 
thus  far  we  have  been  content  to  use  English  prose  tor  this  pur¬ 
pose. 
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V.  RELATION  TO  FORMAL  LANGUAGES  AND  AUTOMATA  THEORY 


We  will  relate  SL  to  the  following  theoretic  models:  pushdown 
automata,  BNF,  finite  automata  and  reqular  expressions. 

Those  lacking  an  affection  for  theory  can  consider  that  SL 
(and  S/SL)  is  a  programming  language  particularly  suited  to  cer¬ 
tain  tasks.  But  the  more  theoretically  inclined  mav  choose  to 
consider  that  SL  is  a  notation  for  defining  deterministic  push¬ 
down  automata.  One  of  our  purposes  here  is  to  show  that  SL  is 
equivalent  in  formal  descriptive  power  to  the  LR  ( k )  technique. 
(See  Aho  and  Ullman  C  1 9  7  7  J  for  theoretic  background). 

A  push  down  automaton  (PDA)  is  a  machine  that  reads  a  stream 
of  tokens  (an  input  tape).  The  PDA  has  an  internal  configuration 
that  consists  of  two  parts:  (1)  one  of  a  finite  number  of  control 
states  together  with  (2)  a  stack.  Each  entry  on  the  stack  has 
one  of  a  finite  number  of  values.  The  PDA  can  read  the  next 
input,  change  its  control  state  and  push  or  pop  its  stack  depend¬ 
ing  on  the  values  of  the  next  input,  the  present  control  state 
and  the  present  top  of  stack. 


I  I  II 

I  I  Finite  I  I 

- >  |  |  |  |  control  I  I  - > 

Input  I  II  I _ - _ I  I  Output 

Stream  III  I  Stream 

I  I I  Stack  I 


Pushdown  Automaton 


If  the  PDA  has  (at  most)  one  possible  chanqe  of  configuration  for 
each  given  input,  control  state  and  stack  top  combination,  it  is 
called  a  dfit.fixaixiist.ic  pushdown  automaton  ( DPD A )  •  if  there  can 
oe  more  than  one  such  possible  changes  then  the  PDA  is  called 

aaaclfit.exaixiist.ic ;  it  is  a  NPDA. 

The  significance  of  the  DPDA  and  NPDA  models  are  the  follow¬ 
ing  : 

(1)  Most  practical  parsers  are  similar  to  the  DPDA.  They  are  act. 
similar  to  the  NPDA,  which  would  require  a  heavy  overhead  to 
keep  track  of  various  possible  sequences  of  configurations 
(various  possible  parsing  sequences). 

(2)  The  NPDA  is  equivalent  to  BNF .  This  means  a  lanauaqe  can  be 
described  by  BNF  if  and  only  if  it  can  be  parsed  bv  a  NPDA. 

In  brief,  the  DPDA  is  a  model  of  practical  parsers  while  the  NPDA 
is  a"model  of  parsers  for  arbitrary  BNF  grammars. 


22 


If  we  limit  ourselves  to  those  languages  which  can  be  accepted 
by  a  DPDA,  then  we  have  deXeiiJiLi.aisX.Lc  lanauaaes.  It  turns  out 
that  this  is  the  same  class  of  languages  that  can  be  described 
by  LR(k)  qrammars.  L.R(k)  is  the  largest  subset  of  RNF  grammars 
for  which  deterministic  parsers  can  be  automatically  generated, 
A  subset  of  the  i.R(K)  grammars,  called  LALRC1),  seems  to  be  the 
best  present  basis  for  parsers  generated  from  bnf  grammars. 

What  is  the  connection  between  SL  and  DPDA?  The  answer  is  that 
each  SL  program  defines  a  DPDA.  The  control  state  is  given  by 
the  present  point  of  execution  in  an  SL  rule.  The  stack  gives 
the  return  points  of  the  presently  active  SL  rules.  It  is  easy 
to  show  that  an  SL  program  can  do  no  more  than  a  DPDA,  because 
the  SL  program  is  effectively  a  special-purpose  DPDA.  We  can 
also  show  that  any  DPDA  can  dp  simulated  by  an  SL  program,  so  we 
get  this  result: 

IXeanem .  A  language  is  LR(k)  iff  it  is  accepted  by  an  SL 
program . 

The  simulation  of  a  DPDA  by  an  SL  program  depends  on  using  SL 
choice  rules  and  is  not  entirely  obvious  fLomet  1973,  Wu  et  al 
1980J  . 

Persons  familiar  with  LR  ( k )  parsers  may  be  surprised  that  SL 
can  recognize  any  language  described  by  an  LR(k)  grammar.  They 
miqht  argue  that  the  k  in  LR(k)  implies  k  tokens  ot  look-ahead 
and  SL  clearly  uses  only  one  symbol  of  look-ahead.  The  flaw  in 
this  argument  is  exposed  by  Knuth's  proof  [Hopcroft  1969J  that 
any  LR(k)  language  (not  grammar)  is  also  an  LR(0)  language,  given 
an  end-marker.  So,  any  LR(k)  language  can  be  recognized  with  no 
look-ahead  at  all.  This  does  not  mean  that  every  LRCk)  qrammar 
is  also  an  LR(O)  grammar?  rather,  it  means  that  any  i,R(k)  grammar 
can  be  rewritten  to  be  an  LR(0)  grammar,  given  an  end-marker. 

Our  theorem  means  that  if  a  parser  for  a  particular  languaqe 
can  be  developed  using  LRCk)  metnods,  then  a  parser  can  be 
developed  using  SL,  and  vice  versa.  This  is  a  theoretic  result 
and  implies  nothing  about  a  host  of  Important  practical  issues. 
It  says  nothing  about  tne  relative  difficulty  of  writing  ap¬ 
propriate  BNF  versus  SL,  and  nothing  about  the  relative  efficien¬ 
cies  of  the  resulting  parsers.  It  does  not  imply  anything  about 
error  handling.  Neither  does  it  imply  anvthinq  about  methods  of 
transduction  or  convenience  of  attaching  semantic  operations  to 
tne  parsing  process. 

Let  us  return  to  the  DPDA  model  and  consider  its  stack  more 
closely,  if  the  stack  is  eliminated  then  we  get  a  finite. 
auXamaXau  (FA),  A  finite  automaton  is  equivalent  to  teoulat 
ex.acecs.ians,  If  we  limit  the  stack  depth  to  any  finite  maximum, 
then  the  DPDA  has  only  the  power  ot  a  FA.  In  terms  of  SL,  this 
means  that  any  non-recursive  SL  program  necessarily  recognizes  a 
reqular  languaqe,  because  without  recursion  the  stack  can  only 
get  so  deep.  Our  example  scanner  clearly  fits  this  pattern. 
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VI.  IMPLEMENTING  S/SL 


Up  to  now  we  have  discussed  s/SL  without  worrying  about  its 
implementation.  w e  have  been  content  to  consider  that  S/SL  is  a 
well-defined  abstraction  supported  perhaps  by  some  special  com¬ 
puter.  This  idea  of  an  abstraction  supported  bv  underlyinq 
software  is  one  of  the  most  important  tools  available  for  struc¬ 
turing  programs  and  is  used  constantly  in  software  enaineering. 

In  this  section  we  will  face  the  implementation  problem.  The 
implementation  is  interesting  because  it  is  simple  and  efficient. 
Qnce  the  implementation  of  S/SL  is  understood,  it  becomes  clear 
how  to  implement  semantic  operations. 

There  are  a  number  of  possible  ways  to  implement  S/SL.  We 
could  transliterate  S/SL  programs  to  Pascal,  producina  a  sequence 
of  procedure  calls  that  implement  the  S/SL  operations  for  input, 
output,  etc.  The  result  would  be  a  “recursive  descent"  compiler. 
While  the  result  would  be  correct,  it  would  be  considerably 
larqer  than  necessary,  and  this  is  not  the  method  we  favor. 

We  could  translate  S/SL  directly  to  machine  lanquaae  for,  say, 
the  PDP-11.  This  too  would  work,  and  the  machine  lanauage  would 
be  very  fast.  But  it  is  relatively  difficult  to  write  code  gen¬ 
erators,  and  we  would  need  to  write  one  tor  each  computer  that  is 
to  support  S/SL. 

Rather  than  generate  code  for  an  existing  computer  architec¬ 
ture,  we  will  invent  an  "S/SL  machine"  which  is  designed  to  make 
S/SL  implementation  easy,  efficient  and  portable. 


An  S/SL  Machine 

Since  S/SL  is  such  a  small  lanquage,  our  machine  will  be  very 
simple.  To  support  the  SL  sunset  of  S/SL  it  will  need  only  these 
12  instructions: 


1 

jumpForward 

label 

2 

j  umpback 

label 

3 

input 

token 

4 

input  Any 

5 

emit 

token 

6 

error 

signal 

7 

inputChoice 

table 

8 

call 

.lapel 

9 

return 

10 

setResult 

value 

11 

choice 

table 

12 

endChoice 

instructions  1  and  2  transfer  control  to  the  qiven  label;  in¬ 
struction  1  jumps  forward  to  its  label  while  instruction  2  jumps 
backward  to  its  label.  Instruction  3  checks  that  its  operand 
matches  the  next  input  and  then  reads  another  input.  Instruction 
4  CinoutAny)  implements  the  "?"  action  by  reading  an  input 
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without  checking  tor  a  match.  Instructions  b  and  6  implement  the 
output  C.)  and  error  (#)  actions#  causing  output  tokens  and  error 
signals  to  be  emitted  to  the  appropriate  streams. 

Instruction  7,  inputChoic^,  Implements  the  input  choice  ac¬ 
tion.  Its  operand  locates  a  table  of  this  form: 

n  (number  of  choices) 
token  label 
token  label 

•  •  • 

token  laoel 
default 

First  comes  a  number  n  diving  the  number  of  alternatives.  Then 
come  n  token/label  table  entries.  The  table  is  searched  from  top 
to  bottom,  trying  to  match  the  present  input  token.  If  a  match 
is  found,  then  control  is  transferred  to  the  label  corresponding 
to  the  token.  If  no  match  is  found  in  the  n  entries,  then  con¬ 
trol  is  given  to  the  default  instruction  followinq  the  table.  If 
the  S/SL  choice  has  an  otherwise  alternative  (*)  then  the  default 
is  the  code  for  otherwise. 

It  there  is  no  otherwise  alternative  then  the  default  is 
reached  only  when  there  is  a  syntax  error  in  the  input  stream. 
The  default  in  this  case  is  an  input  instruction  whose  token  is 
the  first  label  of  the  choice,  followed  by  a  jumpBack  instruction 
which  transfers  to  the  first  alternative.  This  default  forces  a 
mismatch  in  the  input  instruction;  the  mismatch  is  handled  by  the 
strategy  for  handling  syntax  errors  in  input  instructions.  This 
default  is  simple  and  effective  for  most  error  situations,  put 
can  be  specialized  it  desired  to  improve  the  handlina  of  particu¬ 
lar  errors. 

Instruction  8  calls  an  S/SL  rule;  the  rule  is  located  by  the 
call's  label.  Instruction  9  returns  from  a  rule  to  the  instruc¬ 
tion  just  beyond  the  call,  A  stack  is  used  to  hold  the  return 
addresses  of  rules  that  have  been  called  but  have  not  yet  re¬ 
turned. 

Instructions  10,  11  and  12  are  used  to  implement  calls  to 
choice  rules.  The  call  to  a  choice  rule  is  translated  to: 

call  label 
choice  table 

The  call  causes  the  choice  rule  to  execute;  the  rule  leaves  its 
return  value  in  a  variable  called  "result".  The  choice  instruc¬ 
tion  searches  its  table  for  "result",  lust,  as  inputChoice 
searches  Its  table  tor  the  current  token  value,  A  choice  rule 
always  returns  by  executing  ">>  value"  which  is  translated  to: 

setResult  value 
return 

This  assigns  the  value  to  the  "result"  variable  so  it  can  be  used 
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by  the  "choice"  instruction. 

The  choice  taole  is  followed  by  a  default  action.  If  the  S/SL 
choice  had  an  otherwise  alternative  ( *  1  then  the  default  is  the 
code  for  otherwise.  But  it  there  was  no  otherwise  alternative, 
then  the  default  is  the  endChoice  instruction.  This  instruction 
is  reached  only  when  no  labels  ot  alternatives  can  be  matched  and 
there  is  no  otherwise  alternative;  so  endChoice  aborts  the  S/SL 
program . 

Our  twelve  instructions  are  sufficient  to  implement  all  of 
S/SL  except  for  semantic  operations.  We  will  support  each  seman¬ 
tic  operation  by  inventing  a  new  instruction  to  implement  that 
particular  operation.  Before  discussing  these  new  instructions, 
we  will  give  an  example  S/SL  program  translated  into  S/SL  machine 
instructions . 


Translating  S/SL  to  Machine  instructions 

The  mapping  from  an  S/SL  program  to  instructions  for  our  S/SL 
machine  is  straightforward  as  we  will  now  show.  Here  is  our 
SkipNoise  S/SL  rule  translated  to  a  seguence  of  instructions. 


S/SL 

Source 

Assembly  Language 

Location; 

Machine  Code 

SkipNoise ; 

{ 

LI;  inputChoice 

51 

7 

C 

Table 

52 

7 

1  blank : 

L2;  jumpForward 

53 

1 

L.4 

54 

1  2 

1 il legalChar : 

L3;  error 

55 

6 

tfbadChar 

b a dC ha r 

5b 

10 

1  umpForward 

57 

1 

1.4 

5  8 

8 

Table;  2 

59 

2 

blank 

60 

2 

L2 

61 

8 

i  l  legalChar 

6  2 

3 

Li 

63 

8 

1  * : 

i  umpForward 

64 

1 

> 

L5 

65 

3 

) 

L4;  jumpback 

66 

2 

> 

LI 

67 

16 

• 

9 

L5;  return 

68 

8 

The  numbers  representing  the  S/SL  program  in  machine  language  are 
given  on  the  right.  We  have  arbitrarily  started  the  code  tor 
SkipNoise  at  location  51.  The  first  instruction  is  an  in- 
putChoice  (7)  so  location  51  contains  7.  Location  52  holds  the 
relative  location  (7)  of  the  choice  table;  this  7  is  added  to  52 
to  find  the  table  Cat  location  59).  The  next  instruction  is 
"jumpForward  L4"  which  goes  to  the  end  of  the  input  choice.  This 
appears  in  locations  53  and  54  as  1  (jumpForward)  and  12;  12  is  a 
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relative  address  (12  added  to  54  gives  66  which  is  L4's  loca¬ 
tion).  We  have  used  relative  addressing  throughout  to  make  the 
encoding  of  target  labels  more  compact. 

It  is  straightforward  to  design  a  microprocessor  [Lazar  1980) 
or  to  write  a  Pascal  program  to  execute  this  S/SL  machine 
language.  We  are  not  planning  to  build  such  a  microprocessor  in 
the  near  future,  but  we  have  written  the  Pascal  program,  which  we 
will  now  describe. 


An  S/SL  Table  Walker 

We  call  the  sequence  of  numbers  representing  an  S/SL  program 
an  SZSL  Latole.  These  numbers  can  be  stored  in  a  Pascal  array,  A 
Pascal  program  which  accesses  this  table  and  simulates  an  S/SL 
machine  is  called  a  Labia  atalk£L.  It  "walks"  through  the  table 
executing  instructions  and  thus  carrying  out  the  actions  of  the 
S/SL  program. 

We  assume  that  the  following  procedures  have  been  written  in 
Pascal . 

Acceptlnpu tToken  -  this  reads  the  next  token  in  the  input,  stream 
into  the  "token"  variable,  which  is  global  to  the  table  walk¬ 
er. 

Emi tOutputToken  -  this  emits  the  token  that  is  its  parameter  to 
the  output  stream. 

SignalError  -  this  generates  the  error  message  specified  by  its 
parameter.  For  certain  values  of  its  parameter  (for  "fatal" 
errors),  SignalError  sets  "processing"  to  false,  thereby  caus¬ 
ing  the  table  walker  to  terminate. 

HandleSyntaxE:r ror  -  takes  some  appropriate  error  handling  action; 
it  is  called  when  the  present  input  token  is  syntactically 
illegal.  Its  parameter  gives  the  expected  input  token. 

we  have  put  a  small  letter  "o"  as  the  first  letter  of  each  in¬ 
struction  name,  for  example  "return"  becomes  oketurn,  to  avoid 
clashes  with  other  names  in  the  Pascal  program.  We  have  defined 
o JumpFor war d  to  pe  1,  oJumpBack  to  be  2,  olnput  to  be  3,  and  so 
on. 


we  have  factored  out  the  logic  that  searches  tables  in  choice 
actions.  This  logic,  contained  in  the  procedure  named  Choose,  is 
used  by  input  choices,  rule  choices  and  semantic  choices.  This 
version  of  the  table  walker  omits  the  implementation  of  semantic 
operations.  It  is  sufficient  for  implementing  a  compiler  pass 
without  semantic  operations,  such  as  a  parser.  The  next  section 
shows  how  semantic  operations  are  supported.  Here  is  the  table 
walker; 


tablePointer  :=  1;  {Locates  instruction  to  execute} 

returnTop  :=  0;  {Locates  top  ot  return  Stack) 

processinq  ;=  true;  {Is  set  to  false  to  stop  the  table  walker) 

while  processinq  do 
begin 

operation  :=  ss ITab 1 e [ tab lePointer J ; 
tablePointer  :=  tablePointer  +  1; 

case  operation  o t 

oJumpFor ward: 

tablePointer  :=  tablePointer  +  ss liable  [ tablePointer ] ; 
odumpBack : 

tablePointer  :=  tablePointer  *  sslTable  [tablePointer J 

olnpu t : 
begin 

it  token  =  sslTable [ tablePointer 3  then 
Accept InoutToken 
else 

HandleSyntaxError (sslTable [tablePointer)); 
tablePointer  :=  tablePointer  +  1 
end ; 

olnput Any : 

Accept Input To ken; 

oEmi  t : 
begin 

Em itOutputTokenCssl Tab  lettable Pointer)); 
tablePointer  :=  tablePointer  +  1 
end ; 

oError:  ...similar  to  oEmit... 

olnputChoice : 
begin 

choice Table  :=  tablePointer  + 
ss liable [ tab  lePointer  3  ; 
result  :=  token; 

Choose ; 

if  choice Match  then 
AccePtlnputToken 

end ; 
oCal 1 : 

if  returnTop  <  returnSize  then 
begin 

returnTop  :=  returnTop  +  1; 

returnStack t returnTop)  :=  tablePointer  +  1; 
tablePointer  :=  sslTable [tablePointer ) 

end 

else  ...abort,  setting  processinq  to  false... 
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o  R  e  t  u  r  n : 

if  returnlop  >  0  then 

begin 

tablePointer  :=  returnStack treturnTobl ; 
returnTop  :=  return Top  -  1 

end 

else 

processing  :=  false;  (Return  from  main  rule} 

oSetResui t : 
b  e  q  i  n 

result  ;=  ss ITab 1 e t tablePointer 3 ; 

tablePointer  :=  tablePointer  +  1 
end; 

oChoice ; 
begin 

choiceTable  :=  tablePointer  + 
ssl Tab. lettable Pointer] ; 

Choose 
end ; 

oEndChoice:  ...abort,  settina  processing  to  false... 

, • .alternati ves  to  implement  semantic  operations... 

end  (  case  } 
end  (  while  } 

As  can  be  seen  by  reading  this  program,  it  is  a  simulator  for  an 
S/SL  machine. 

The  instructions  j umpFor ward  and  jumpBack  are  implemented  as 
jumps  relative  to  the  current  value  of  tablePointer.  Similarly, 
in  the  inputCnoice  and  choice  instructions,  the  choice  tables  are 
located  relative  to  the  current  tablePointer.  This  use  of  rela¬ 
tive  addressing  together  with  separate  forward  and  backward  lumps 
makes  it  relatively  easy  to  compact  the  sslTable  to  use  byte 
entries.  For  this  compaction  to  be  practical,  we  would  need  to 
encode  the  label  in  a  call  instruction  into  two  bytes,  but  we 
will  not  go  into  these  optimizations  here. 


Supporting  Semantic  operations 

Our  taole  walker  supports  SL  but  not  S/SL.  To  support  S/SL  it 
must  be  enhanced  with  new  instructions.  We  add  a  new  alternative 
to  the  table  walker's  case  statement  tor  each  semantic  operation. 
For  example,  the  CountPop  semantic  operation  can  be  implemented 
by 


oCountPop ; 

countTop  :=  countTop  -  1; 

where  countTop  is  a  variable  pointing  to  the  top  of  the  count 
stack . 
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we  also  invent  the  following  special  instruction  to  help  im¬ 
plement  parameterized  semantic  operations: 

13  setParameter  value 

This  instruction  (number  13)  assigns  its  value  to  a  variable 
called  "parameter''.  Before  invoking  a  parameterized  semantic 
operation,  such  as  CountPush,  a  setParameter  instruction  is  exe¬ 
cuted  to  give  the  appropriate  value  to  "parameter " .  For  example, 
PushCount ( zero )  in  S/SL  is  translated  into  the  instructions: 

setParameter  zero 
CountPush 

We  translate  a  semantic  choice  operation  into  an  instruction 
to  invoke  the  operation  followed  by  a  choice  instruction.  For 
example,  CountChoose  in  S/SL  is  translated  to  the  instructions: 

CountChoose 
choice  table 

The  CountChoose  instruction  assigns  to  the  variable  named 
"result",  and  the  choice  instruction  searches  its  table  for  this 
value , 
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VII.  EXPERIENCE  AND  OBSERVATIONS 


Experience  usinq  S/SL 

S/SL  has  been  used  in  implementing  three  compilers:  Speckle  (a 
PL/1  subset  [Miceli  197  7  3  #  Toronto  Euclid  [Holt  197  8  3  #  and  PT  (a 
Pascal  subset)  [Rosselet  1980] ;  it  has  also  been  used  to  imple¬ 
ment  an  S/SL  processor.  Previous  to  S/SL,  syntax  and  semantic 
charts  tCordy  1979]  had  been  used  by  tne  authors,  most  notably 
for  implementing  SP/k  (a  PL/1  subset)  [Holt  1977J.  These  charts 
are  hignly  readable  and  have  an  efficient  implementation.  Their 
primary  disadvantage  is  that  they  are  not  machine  readable  and, 
like  flowcharts,  are  difficult  to  maintain. 

when  designing  the  Euclid  compiler,  we  contemplated  usinq 
charts,  but  decided  to  use  S/SL  instead.  This  turns  out  to  have 
been  a  fortuitous  decision,  as  we  now  believe  that  the  iob  would 
not  have  been  possiole  using  charts,  what  we  had  not  predicted 
was  the  sheer  bulk  of  programs  in  S/SL  needed  to  compile  a 
language  like  Euclid.  Five  passes  of  the  Euclid  compiler 
(parser,  table  builder,  type  conformance  checking,  storage  allo¬ 
cation  and  code  generation)  were  written  in  S/SL,  with  a  total  of 
about  24,000  lines  of  S/SL  code.  It  would  probably  not  have  been 
possiole  to  keep  track  of  the  equivalent  volume  of  hand-drawn 
charts . 

The  technique  of  software  development  used  in  the  Euclid  com¬ 
piler  was  based  on  S/SL  pass  skeletons  in  the  following  manner. 
First  a  parser  was  developed  for  the  Euclid  source  languaqe;  this 
parser  produced  an  output  stream,  which  we  will  call  I-code 
(intermediate  code).  I-code  is  essentially  the  complete  syntax- 
checked  Euclid  program,  encoded  as  a  sequence  of  tokens.  About 
the  only  interesting  t rans f ormat ion  from  the  source  is  that  most 
operators  have  been  moved  into  postfix  positions. 

Once  the  parser  was  implemented,  an  S/SL  program  was  written 
to  accept  an  I-code  stream  and  reproduce  the  same  stream  as  out¬ 
put,  This  seemingly  useless  program  served  two  key  purposes. 
First,  it  formally  specified  the  stream  coming  out  of  the  parser. 
Second,  it  served  as  a  skeleton  for  each  of  the  following  passes 
of  the  compiler.  Each  of  these  passes  makes  only  minor  modifica¬ 
tions  on  tne  stream;  most  information  is  relayed  to  the  following 
passes  via  the  symbol/type  table.  Each  pass  was  constructed  by 
modifying  the  skeleton  S/SL  program,  most  commonlv  by  adding 
calls  to  semantic  operations.  As  a  result,  all  of  these  passes 
are  similar  in  structure,  and  the  whole  compiler  is  relatively 
easy  to  understand. 

As  each  pass  executes,  its  S/SL  parses  the  pass's  input 
stream.  This  parsing  provides  an  important  check  on  the  inter¬ 
face  between  passes,  verifying  that  the  input  I-code  stream  is 
syntact ical ly  correct. 

In  general  the  experience  of  writing  several  compilers  usinq 
S/SL  has  been  a  happy  one.  The  S/SL  programs  have  been  relative¬ 
ly  easy  to  write  and  maintain.  The  computer  time  spent  executing 
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code  written  in  S/SL  has  been  small  compared  to  time  scent  in 
other  activities,  such  as  input/output .  The  tables  produced  by 
S/SL  together  with  the  table  walker  are  observed  to  be  quite 
small,  better  than  or  comparable  to  other  techniques  such  as 
writing  in  a  high  level  language  or  using  LR(k), 


Using  S/SL,  tor  Non -Compiler  Applications 

Although  S/SL  evolved  as  a  tool  for  constructing  compilers,  it 
appears  to  be  useful  tor  a  much  larger  class  of  problems.  The 
concept  of  a  pure  control  language  and  abstract  data  (semantic 
mechanisms)  are  not  intrinsically  tied  to  compiler  writing.  In 
non-compiler  applications,  these  concepts  become  the  center  of 
focus  while  stream-oriented  features  (input  and  output  of  tokens) 
become  more  peripheral,  although  still  widely  useful. 

In  the  future  we  expect  to  experiment  with  S/SL  as  a  software 
specification  language.  As  such  an  S/SL  program  will  serve  as 
the  top  level,  executable  design  for  a  system,  which  is  to  be 
implemented  later  by  programming  its  semantic  mechanisms.  For 
large  systems,  these  implementations  may  in  turn  be  designed 
usinq  S/SL,  the  result  being  several  levels  of  S/SL  implementing 
increasing  levels  of  detail  of  the  system. 


A  Synthesis  of  Ideas 

The  S/SL  language  is  a  synthesis  of  several  programming  con¬ 
cepts.  The  following  related  notations  have  been  directly  in¬ 
fluential  . 

(a)  BNF  and  regular  expressions, 

(b)  Syntax  charts  and  semantic  charts. 

(c)  Recursive  descent  compilers  (written  in  Pascal-like 
languages ) • 

(d)  Separable  transition  diaqrams  [Conway  1963) • 

(e)  Table-driven  coding,  such  as  the  scheme  used  in  the 
PL/C  compiler  [Wilcox  1971]. 

(f)  Data  encapsu 1  a t i on  techniques,  such  as  those  in  Simula 
and  Fuclid. 

What  seems  encouraging  about  S/SL  is  that  it  captures  such  a 
large  fraction  of  the  power  of  these  notations,  while  itself 
remaining  so  simple. 

There  are  many  possibilities  for  expansion.  One  could  make 
S/SL  into  a  Pascal-like  language  by  introducing  declarations, 
expressions  and  assignments.  The  result  might  be  particularly 
attractive  as  an  interactive  lanquage,  due  to  the  conciseness  of 
programs.  Another  possibility  would  be  to  allow  several  input 
streams  and  output  streams.  If  we  also  allow  several  processes 
then  the  language  becomes  similar  in  form  and  concept  to  Hoare's 
cooperating  sequential  processes. 

Generally  we  have  resisted  the  urge  to  expand  s/SL,  on  the 


principle  that  "small  is  beautiful".  Its  simplicity  results  in 
readability,  a  great  deal  of  flexibility  and  an  easy,  efficient 
implementation . 
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SPECIFICATION  OF 
S/SL:  SYNTAX/SEMANTIC  LANGUAGE 
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(Revised  March  1980) 


ABSTRACT 

This  document  defines  "new"  S/SL,  the  second  qeneration  of  the 
Syntax/Semantic  Lanquaqe.  S/SL  is  a  programming  lanquaqe 
developed  at  the  Computer  Systems  Research  Group,  University  of 
Toronto  as  a  tool  tor  constructing  compilers.  It  has  been  used 
to  implement  scanners,  parsers,  semantic  analyzers,  storage  allo¬ 
cators  and  machine  code  generators,  S/SL  has  been  used  to  imple¬ 
ment  compilers  for  Euclid,  FT  Pascal  and  Speckle,  a  PL/1  subset. 


Copyright  (C)  1979,  1980  by  the  University  of  Toronto,  This 
work  was  supported  in  part  by  the  Natural  Sciences  and  Engineer¬ 
ing  Research  Council  of  Canada  and  by  Bell-Northern  Research  Lim¬ 
ited. 
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introduction 


S/SL  is  a  procedure-based  variable-free  programming  language 
in  which  the  program  logic  is  stated  usinq  a  small  number  of  sim¬ 
ple  control  constructs.  Ft  accesses  data  in  terms  of  a  set  of 
operations  organized  into  dat a-management  modules  called  mechan¬ 
isms.  The  interface  to  these  mechanisms  is  defined  in  S/SL.  but 
their  implementation  is  hidden  from  the  S/SL  program. 

S/SL  has  one  .input  stream  and  one  output  stream,  each  of  which 
is  strictly  sequential.  These  streams  are  organized  into  "to¬ 
kens"  each  of  which  is  read  and  written  as  a  unit.  An  auxiliary 
output  stream  for  error  diagnostics  is  also  provided. 


IDENTIFIERS,  STRINGS  AND  INTEGERS 

An  S/SL  identifier  mav  consist  of  any  string  of  up  to  50 
letters,  digits  and  underscores  („)  beginning  with  a  letter. 
Upper  and  lower  case  letters  are  considered  identical  in  S/SL, 
hence  aa,  aA,  Aa  and  AA  all  represent  the  same  identifier. 
INPUT,  OUTPUT,  ERROR,  TYPE,  MECHANISM,  RULES,  DO,  OD ,  IF,  FI,  END 
and  their  various  lower  case  forms  are  keywords  of  S/SL  and  must 
not  be  used  as  identifiers  in  an  S/SL  program. 

An  S/SL  string  is  any  sequence  of  characters  not  including  a 
quote  surrounded  by  quotes  (#). 

Integers  may  oe  siqned  or  unsigned  and  must  lie  within  a  range 
defined  by  the  implementation.  For  example,  this  range  could  be 
-32767  to  32767  on  the  PDP-11, 

Identifiers,  keywords,  strings  and  inteqers  must  not  cross 
line  boundaries.  Identifiers,  keywords  and  integers  must  not 
contain  embedded  blanks. 


COMMENTS 

A  comment  consists  of  the  character  "%"  (which  is  not  in  a 
string)  and  the  characters  to  the  right  of  it  on  a  source  line. 


CHARACTER  SET 


Since  not  all  of  trie  special  characters  used  in  S/SL  are 
available  on  all  machines,  the  following  alternatives  to  special 
characters  are  allowed. 


II  1  If 
• 

for 

If  |  II 

"  DU" 

for 

••  ^  »i 

"OD" 

for 

II  |  If 

"IF" 

f.or 

"  [ " 

"El" 

for 

"] " 

2  - 


' 
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SOURCE  PROGRAM  FORMAT 

S/SL  programs  are  free  format;  that  is,  the  identifiers,  key¬ 
words,  strinqs,  integers  and  special  characters  which  make  up  an 
S/SL  program  nay  be  separated  by  any  number  of  blanks,  tab  char¬ 
acters,  form  feeds  and  source  line  boundaries. 


ROT ATI  ON 

The  following  sections  define  the  syntax  of  S/SL.  Throughout 
the  following,  (item)  means  zero  or  more  of  the  item,  and  litem} 
means  the  item  is  optional.  The  abbreviation  "id"  is  used  for 
identifier . 


PROGRAMS 

An  S/SL  program  consists  of  a  set  of  definitions  followed  by  a 
set  of  rules. 

A  ataatata  i  s : 


[ inputDef init ionj 
toutputDef ini tion) 
CinputOutputDefinitionJ 
[ err or Def init ion] 

(typeOr Mechanism Definition) 
RULES 
(rule) 

END 


INPUT  AND  OUTPUT  DEFINITIONS 

An  laautUatialtlaa  is: 

input  " : " 

{ tokenDef inition) 


An  autuutQ£.tjLalliaa  is: 

output 

{ tokenDef in ition) 


An  luautQui.aui.iuati.al Liao,  is: 

INPUT  output  " : " 

(tokenDef inition) 
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A  is 


id  (string]  ["  =  "  tokenVaiuel 


The  inputDefinition  section  defines  the  input  tokens  to  the 
S/SL  program.  The  outputDefinition  section  defines  the  output 
tokens  of  the  program.  The  inputUu tputUef init ion  section  defines 
those  tokens  which  are  both  input  tokens  and  output  tokens  of  the 
program.  Tokens  already  defined  in  the  inputDefinition  or  out¬ 
putDefinition  sections  must  not  be  redefined  in  the  inputOutput- 
Definition  section. 

The  optional  string  which  may  be  qiven  in  a  token Definition  is 
a  synonym  for  the  token  identifier  and  can  be  used  in  place  of 
the  identifier  anywhere  in  the  S/SL  program. 

Each  input  and  output  token  is  assigned  an  integer  value  for 
use  in  the  implementation  of  the  S/SL  program.  This  value  may  be 
optionally  specified  in  each  tokenDef inition.  The  tokenValue  may 
be  specified  as  an  integer  or  as  the  value  of  anv  previously 
defined  identifier  or  string.  if  omitted,  the  value  assigned  to 
the  token  is  the  value  associated  with  the  previous  token  in  the 
class  plus  one.  The  default  value  associated  with  the  first 
input  token  and  the  first  output  token  is  zero.  The  default 
value  associated  with  the  first  input-output  token  is  the  maximum 
of  the  last  token  defined  in  the  inputDefinition  section  and  the 
last  token  defined  in  the  outputDefinition  section.  In  this  way 
the  default  input-output  token  values  are  unique  with  respect  to 
both  input  tokens  and  output  tokens. 


ERROR  SIGNALS 


An  acxac.UatiQii.ian  is: 

ERRUk  " 

(errorSignalDefinition)  " ; " 


An  ad.axSiaaaiUaiiait.ian  is: 

id  [ M = ”  errorVa] ue] 


Each  errorSignalDefinition  defines  an  error  signal  which  can 
be  signalled  by  the  S/SL  program.  An  integer  error  code  value  is 
associated  with  each  errorid  for  use  in  the  implementation  of  the 
S/SL  program.  This  value  may  be  optionally  specified  in  each 
errorSignalDefinition.  The  errorVaiue  may  be  specified  as  an 
integer  or  as  the  value  of  any  previously  defined  identifier  or 
string.  The  default  value  associated  with  an  error  signal  is  the 
value  associated  with  the  previous  error  signal  Plus  one.  The 
default  value  for  trie  first  error  signal  is  10  (errors  0  to  9  are 
reserved  for  S/SL  system  use). 
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TYPE  AN  l)  MECHANJ5M  DEFINITIONS 


Type  and  mechanism  definitions  may  ne  grouped  and  intermixed 
to  reflect  the  association  of  types  and  the  operation  definitions 
which  use  them. 

A  is  one  of: 

a.  typeDef ini t ion 

b.  mechanismDef inition 


TYPES 


A  L^aeQ&txuitian  is: 

TYPE  id 

{valueDef inition)  M ? " 


A  italue.Uetiai.tiau  is: 

id  ["="  value] 


Each  typeDef inition  defines  a  type  of  values  for  use  as  the 
parameter  or  result  type  of  a  semantic  operation  or  as  the  result 
type  of  a  rule. 

Each  valueDef inition  defines  a  valueld  in  the  type.  An  in¬ 
teger  value  is  associated  with  each  valueld  for  use  in  the  imple¬ 
mentation  of  the  S/SL  program.  This  value  may  be  optionally 
specified  in  each  valueDef in  it  ion.  The  value  may  be  specified  as 
an  integer  or  as  the  value  of  any  previously  defined  identifier 
or  string.  The  default  value  assigned  to  a  value  identifier  is 
the  value  associated  with  the  previous  value  identifier  plus  one. 
The  default  value  associated  with  the  first  valueDef inition  in  a 
type  is  zero. 


MECHANISMS 


A  uacUaal&aU&llulllQU  is: 

MECHANISM  id 

{ operat  ionOef ini t ion >  M ; " 


Each  mechanismDef inition  defines  the  set  of  semantic  opera¬ 
tions  associated  with  a  semantic  mechanism.  The  mechanism! d 
itself  is  unused  in  the  S/SL  program.  However,  operation  iden¬ 
tifiers  associated  with  a  mechanism  are  by  convention  expected  to 
begin  with  the  mechanism  identifier. 
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An  apfitationIifii.iaitJ.aa  is  one  of 


a .  id 

b •  id  " ( "  type  id  "  )  " 

c.  id  ">>"  typeld 

d.  id  " C "  typeld  ")H  ">>H  typeld 


Eacn  operationuefinition  defines  a  semantic  operation  associ¬ 
ated  with  the  mechanism. 

Form  Ca)  defines  an  UDdate  semantic  operation,  which  causes  an 
update  to  the  semantic  data  structure. 

Form  (b)  defines  a  parameterized  update  operation,  whicn  uses 
the  parameter  value  to  update  the  semantic  data  structure.  The 
typeld  gives  the  type  of  the  parameter  and  can  be  any  previously 
defined  type. 

Form  (c)  defines  a  choice  semantic  operation,  which  returns  a 
result  value  obtained  from  the  current  state  of  the  semantic 
mechanism,  which  is  used  as  the  selector  in  a  semantic  choice. 
The  typeld  gives  the  type  of  the  result  and  can  be  anv  previously 
defined  type. 

Form  (d)  defines  a  parameterized  choice  operation.  The  first 
typeld  gives  the  parameter  type,  the  second  the  result  type. 
Each  can  be  any  previously  defined  type. 

Choice  operations  (forms  (c)  and  (d)  above)  may  be  invoked 
only  as  the  selector  in  a  semantic  choice. 


RULES 


A  mlfi  is  one  of; 

a .  id";" 

{action)  " ; ” 

p.  id  ">>"  typeld 

{action)  " ; " 


The  rules  define  the  subroutines  and  functions  of  the  S/SL 
program.  Rules  may  call  one  another  recursively.  A  rule  need 
not  be  defined  before  it  is  used.  Execution  of  the  nroqram  be¬ 
gins  with  the  first  rule. 

Form  (a)  defines  a  atacfidura  rule  which  can  be  invoked  using  a 
call  action. 

Form  (b)  defines  a  caaicfi  rule  which  returns  a  result  value  of 
the  specified  type.  The  typeld  can  be  anv  previously  defined 
type.  Choice  rules  may  only  be  invoked  as  the  selector  in  a  rule 
choice. 
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A  C  T  L  u  N  S 


An  acXiao.  is  one  ot  tne  following: 


d  . 
b  • 

c . 

d . 


e , 
t . 


q . 
h . 
i  • 


j . 
K . 
U 
m . 


n . 


i nput Token 

out  put Token 
"  #  "  e  r  r  o  r  I  d 

•I  { H 

{action  ) 

•I  j  m 
ii  ^  it 
..  { ,, 

{"I"  inputToken  {","  inputToken) 
{action)  ) 

I*  ii  I  ii  ii  ^  n  ii  •  H 

{action)  J 

it  j  ii 

" @ "  procedureRuleld 

”["  choiceRuleld 

{"I"  valueld  { " , "  valueld) 

{action)  ) 

j-  ii  I  H  ii  ^  ii  H  •  ii 

{action)  J 

..  j  i, 

">>"  valueld 
update  rip  id 

parame t er izedUpdat eOp ] d  "  ( "  valueld  ")" 
M t "  choiceOpId 


{"  I 

"  valueld 

{","  valueld) 

ti .  ii 

• 

{action) 

) 

C "  1 

•  1  M  ^  II  II  .  II 

{action) 

) 

parameter izedChoiceUpId  " ( 

"  valueld 

{"  i 

"  valueld 

{","  valueld) 

II  •  If 
• 

{action) 

) 

["  1 

if  H  *  n  ii  •  ii 

~  • 

{action) 

J 

..  j  i. 
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Form  (a)  is  an  input  action.  The  next  input  token  is  to  be 
accepted  from  tne  input  stream .  It  it  is  not  the  one  specified, 
a  syntax  error  is  tlagqea.  The  inputToken  may  be  an  inputTok- 
enld,  an  inputuutputTokenld ,  an  inputTokenSt r inn ,  an  inputOutput- 
TokenStrinq,  or  a  question  mark  (?),  The  question  mark  is  a  spe¬ 
cial  token  which  matches  any  input  token. 


Form  (b)  denotes  emission  ot  an  output  token  to  the  output 
stream.  The  outputToken  may  be  an  output  Token  id ,  an  inputOutput- 
Tokenld,  an  outpu tTokenSt. r inn  or  an  inputOu tpu tTokenst r ing • 


Form  (c)  denotes  the  emission  ot  the  specified  error  signal  to 
the  error  stream. 


/ 


Form  (d)  is  a  cycle  or  loop.  Execution  of  the  actions  inside 
the  cycle  is  repeated  until  one  of  its  cycle  exits  (form  (e))  or 
a  return  (forms  (.  h )  and  (1))  is  en countered,  A  cycle  exit  causes 
execution  to  continue  followina  tne  nearest  enclosing  cycle.  The 
cycle  exit  action  is  not  allowed  outside  of  a  cycle. 

Form  (f)  is  an  input  token  c noice.  The  next  token  in  the 
input  stream  is  examined  and  execution  continues  with  the  first 
action  in  the  alternative  labelled  with  that  innut  token.  The 
matched  input  token  is  accented  from  tne  input  stream. 

Fach  inputToken  label  can  be  an  inputTokenld ,  an  inputoutput- 
lokenld,  an  input TokenStr inq  or  an  inputOu tputTokenStr inq .  A 
lapel  can  not  oe  repeated  nor  appear  on  more  than  one  alterna¬ 
tive. 

The  alternative  labelled  with  an  " * "  is  the  otherwise  alterna¬ 
tive,  If  the  next  input  token  does  not  match  any  of  the  alterna¬ 
tive  labels  of  the  choice,  execution  continues  with  the  first 
action  in  the  otherwise  alternative.  If  the  otherwise  alterna¬ 
tive  is  taken,  the  input  token  is  not  accepted  from  the  input 
stream,  but  remains  as  the  next  input  token.  After  execution  of 
the  last  action  In  an  alternative  of  the  choice,  execution  con¬ 
tinues  following  the  choice. 

If  the  next  input  token  does  not  match  any  of  the  alternative 
labels  and  no  otherwise  alternative  is  present,  a  syntax  error  is 
flagged.  For  parsers  written  in  s/SL,  the  default  error  handling 
strategy  is  to  repeat  the  choice  after  modifying  the  input  stream 
sucn  that  the  next  input  token  matches  the  first  alternative. 
For  compiler  phases  other  than  parsers,  continued  execution  is 
undefined  (the  implementation  aborts). 

Form  (g)  is  a  call  to  a  procedure  rule.  Execution  continues 
at  the  first  action  in  the  specified  rule.  when  execution  of  the 
called  rule  is  completed,  either  ny  executing  the  last  action  in 
the  rule  or  by  encountering  a  return  action  (form  (h)),  execution 
is  resumed  following  the  call. 

Form  ( h)  is  a  return  action.  It  causes  a  return  from  the  pro¬ 
cedure  rule  in  which  it  appears.  A  procedure  rule  may  return 
explicitly  by  executing  a  return  action  or  implicitly  by  reaching 
the  end  of  the  rule.  A  procedure  rule  must  not  contain  a  valued 
return  (form  ( j ) )  . 

Form  (i)  is  a  rule  choice.  The  specified  choice  rule  is 
called  and  returns  a  value  bv  executing  a  valued  return  action 
(form  (j)).  The  returned  value  is  used  to  make  a  choice  similar 
to  an  input  token  choice  (form  (f)  above).  Execution  continues 
with  the  first  action  of  the  alternative  whose  label  matches  the 
returned  value.  It  none  of  the  alternative  labels  matches  the 
value,  the  otherwise  alternative  is  taken.  Followino  execution 
of  the  last  action  in  the  chosen  alternative,  execution  continues 
following  the  cnoice. 

Fach  alternative  label  in  a  rule  choice  must  be  a  value  of  the 
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result  type  ot  trie  choice  rule.  A  laoel  can  not  be  repeated  nor 
appear  on  more  than  one  alternative. 

Form  (j)  is  a  valued  return  action.  The  specified  value  is 
returned  as  the  result  of  the  choice  rule  in  which  the  action 
appears.  The  value  must  be  of  the  result  type  of  the  choice 
rule.  A  choice  rule  may  return  only  by  executing  a  valued  return 
action.  A  choice  rule  must  not  return  implicitly  by  reaching  the 
end  of  the  rule.  It  must  not  contain  a  non-valued  return  (form 
(h)). 

Form  (k)  is  the  invocation  of  an  update  semantic  operation. 
Similarly,  form  (11  is  the  invocation  of  a  parameterized  update 
operation.  The  parameter  value,  which  must  be  of  the  operation's 
parameter  type,  is  supplied  to  the  invocation  of  the  operation. 

Form  (m)  is  a  semantic  choice.  The  specified  choice  semantic 
operation  is  invoked  and  the  returned  value  used  to  make  a  choice 
similar  to  an  input  token  choice  (form  (f)  above).  Execution 
continues  with  the  first  action  of  the  alternative  whose  label 
matches  the  returned  value.  If  none  ot  the  alternative  labels 
matches  the  value,  the  otherwise  alternative  is  taken.  Following 
execution  of  the  last  action  in  the  chosen  alternative,  execution 
continues  following  the  choice.  Similarly,  form  (n)  is  a 
parameter i zed  semantic  choice.  The  parameter  value,  which  must 
be  of  the  operation's  parameter  type,  is  provided  to  tne  invoca¬ 
tion  of  the  choice  operation. 

Each  alternative  label  in  a  semantic  choice  must  be  a  value  of 
the  result  type  of  the  choice  operation.  A  label,  can  not  be 
repeated  nor  appear  on  more  than  one  alternative. 

If  the  returned  value  in  a  rule  choice  or  semantic  choice  does 
not  match  any  of  the  alternative  labels  and  no  otherwise  alterna¬ 
tive  is  present,  continued  execution  is  undefined  (the  implemen¬ 
tation  aborts ) . 


THE  SYNTAX  OF  5/SL, 


A  aaaataffl.  i  s  : 


( inpu  CDef init ionj 
toutputDef ini t  ion J 
L  input  UutputDef.  init  ion  J 
[errorUef ini tionJ 
{typeur Mechanism Definition) 
RULES 
{rule) 

E  N  D 


An  iauLit.Qaliai.t.iuu  is: 

input 

{ tokenDef ini t ion) 


An  aaJLauLUfi..tiajU.laa  is: 

OUTPUT 

{ t.  o  k  e  n  D  e  f  i  n  i  t  i  o  n  >  "  ?  M 


An  iauutQutaui.U&JLLa±Liaa  is: 

INPUT  OUTPUT  " : H 

{ t  o  K  e  n  D  e  f  i  n  i  1 1  o  n  >  "  ;  " 


A  LaLaaU&tlalXxaa  1 s : 

id  tstrinqi  lM=H  toKenValueJ 

An  atratUaiiaititta  is: 

error 

{err orSiqndlDet init ion}  " ? " 

An  aai:aaSXaaalUatxaXti.aa  is: 

id  t " = "  errorValue] 

A  LstueQtfiAecuaaismLifiiiaiJLioo  is  one  of: 

a,  typeDet init ion 
o.  mechan i smDef ini t ion 
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A  LitaeUaliaiLian  1  s 


iypf:  id 

{vaiueDefrinition) 


A  M.ai4i6U&£,iaiJtioa  is: 

id  C " = "  value] 


A  m.achaax&aUcJtJL&iLxaa  i  s  : 

MECHANISM  id 

{operation Definition)  " ? " 


A  tula  is  one  of: 


a . 

id  " 

.  ii 
• 

{action)  " ; M 

b  • 

id  " 

>>"  type  Id  " : " 
{action}  " ; " 

of 

the 

f oi  lowing: 

d  . 

inputToken 

b . 

ff  99 

• 

ou toutToken 

c . 

"#  " 

error  I d 

d . 

ii  ^  H 

{ ac t ion) 

ii  |  ii 

e . 

ii  ^  ii 

f . 

it  ^  ii 

{ " 1 "  inputToken 

{action)  > 

1  H  1  ii  H  ^  H  M  •  H 

{action)  3 

ii  j  ii 

q . 

"  @  " 

procedureRuleld 

h  • 

A 

A 

i . 

ii  (  il 

"  @  "  choiceRuleld 

I . 
K. 
1  . 


inputToken)  ”:H 


{ "  I"  valueld  {”,"  valueld} 
{action)  ) 

pi  |  M  »«  $  M  If  •  ff 

{action)  3 


m  i  •• 


J 

"  >  >  M  valueld 
upda teOp I d 

parameter  i  zedllpdateUp  Id  "("  valueld  M)H 
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m .  "l"  choicelJp Id 

{ " I "  value  I d  { "  , "  valueld> 

{ a  c  1. 1  o  n  ►  > 

^  II  |  II  If  $  M  If  •  M 

{action!  I 

If  J  fl 

n*  "C"  parameter izedChoiceOpId  "(" 
{ " I "  v a 1 u e X d  { " f "  value  la) 
{action!  ! 

I  M  |  m  ii  $  H  n  «  ii 

{action!  ] 

fl  1  fl 


II  •  II 


valueld  " ) " 

H  •  H 
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